IBIS Macromodel Task Group Meeting date: 27 March 2018 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte SPISim: Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Arpad to prepare a second draft of the new BIRD to supersede BIRD158.7. - Done. (A draft2 was prepared in time for the previous week's meeting but was not yet discussed). -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Discussion: Radek noted that his comments at the previous meeting had been captured correctly, but he subsequently realized that the Ext_Gnd_Ref in Randy's model was in fact internal to the subcircuit and not exposed as an external node for the overall model. Therefore, this node had no special significance. - Arpad: Does anyone have any comments or corrections? [none] - Radek: Motion to approve the minutes. - Mike L.: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD189 and BIRD158 related issues: - Arpad: Michael Mirmak had asked the question, "What happens to BIRD189 if we ignore BIRD158 for the time being?" - My answer is that BIRD189 has no dependence on BIRD158, but there may be a dependence in the other direction. - We may just need to tailor BIRD158 to BIRD189. - Radek: We have an unfinished discussion of A_gnd. - We need a clear understanding of any BIRD189 interconnect and how it should be handled in AMI simulations, not just BIRD158 simulations. - Discussion: Walter asked the rhetorical question, "Right now, does BIRD189 work with [External Model]?" Walter then noted that BIRD158 is simply a shortcut approach to an [External Model]. Bob and Radek noted that BIRD158 was confined to AMI applications. Walter noted that BIRD158 provides Info type parameters so the tool can configure the analog model for the step response calculation. It does not depend on .dlls, equalization, etc., or any AMI specific concepts. Arpad and Bob noted that [External Model] may use the seven defined terminals analogous to all the implicit [Model] terminals. BIRD158, on the other hand, provides no way to get power and ground rails to the buffer model and assumes ideal rails. Walter noted that one could take a BIRD158 Ts4file model and create an exact equivalent of it by using [External Model] to wrap a subcircuit containing the S-parameter data. [External Model], as a replacement for [Model], only goes as far as the buffer pads. It can work with BIRD189, and therefore there is no issue with BIRD158 with respect to BIRD189. Arpad noted that until we have final agreement on BIRD189 there is nothing to do on BIRD158. Walter noted that BIRD158 does not contain "A_gnd". Arpad agreed, but noted that it does contain the triangle reference symbols, and the text vaguely explains them as "typically ... the global ground". Walter noted the he thought we needed to decide whether A_gnd is a local reference or the equivalent of node 0. Walter said he would make a motion at some point to define it as node 0. Bob noted that the latest (draft2) version of Arpad's proposed update to BIRD158 had changed the language to include "A_gnd". Arpad shared his draft2 email and reviewed it. He noted that "typically be the global ground" was vague, and he had changed the text to define the triangle symbols as "local reference node, A_gnd of the IBIS [Model]" instead. Walter noted that every other place in the IBIS spec that provided figures of this type was referring to a device under test, i.e., the device being "measured" to create the IBIS model. In that case the triangle reference symbol would be the test fixture ground, which would be node 0 if you were "measuring" with simulation. Walter noted that IBIS describes how the model is made, not how it should be used. Bob agreed with this statement with respect to the S-parameter data. However, he noted that a BIRD158 model is a simulation model because it defines Vp and Vn (Tx_V) that should be used at simulation time. So, it's a model made for use in AMI simulation. Radek agreed that we have to make it clear how to use the model. Arpad said that to avoid a debate over whether the figure is a measurement figure or a simulation time figure we should add some explanatory text. Radek noted that we should add the word "model" at the end of the Figure title ("Transmitter Analog Circuit" becomes "Transmitter Analog Circuit Model"). Arpad suggested we table the measurement/simulation discussion so he could think about what language we might add. Ambrish noted that he thought we had also agreed to add language stating that if you're using BIRD158, then you should not expect your simulation to be power aware. Radek noted this was true of any AMI simulation. Arpad noted that adding such language might be problematic if some vendors were to claim they can make use of power aware models in AMI simulations. Walter provided one example of a method for incorporating some power aware effects into a BIRD158 simulation. He said one might fold time varying rail information into a BIRD158 simulation by modulating the values of Vp and Vn. Arpad noted that he didn't think we should add any text discussing "power aware". He noted that it is understood that an AMI model is an LTI model. Questions from the Quality group regarding parser decisions (BIRD158): - Arpad: The Quality group asked a question about Rx_R. - Text says if Rx_R is not present, it should default to open. - However, it doesn't restrict the range of allowable values if it is present. - Quality group is asking if it should be >=0 or >0. - Bob: We (Quality) propose that we add to Arpad's new BIRD158 replacement BIRD. - "... value of Rx_R in Ohms (greater than 0)." - Discussion: Arpad modified his draft2 to add the "(greater than 0)" text to the Rx_R and Tx_V sections. Radek noted that it could be done in a better way grammatically. Walter noted that in other places, Rref_rising for example, the spec does not explicitly state that it has to be a positive number. He asked why we would start now. Radek agreed that it was obvious. Walter said that adding new text was unnecessary, and the parser could simply adopt the check for > 0. Radek noted that the topic had been discussed at the last IBIS Open Forum meeting, and the parser could issue an error or a warning, either was fine. He noted that no model maker will intentionally use unreasonable values. Bob noted that it was true that we hadn't done it before, but that these questions had come up while attempting to craft a parser development contract. He noted that if we can't define it in the spec then we can't put it in the parser contract. Questions from the Quality group regarding parser decisions (BIRD179): - Discussion: Mike L. noted that the example for Special_Param_Names contained a single-column Table with one parameter name per row. He asked if ibischk should require the names to be in a single column. He noted that Supporting_Files explicitly specifies a single column of one or more rows. Bob suggested an editorial change to copy the text from Supporting_Files into BIRD179. Walter agreed. Arpad agreed that a single column was his intent. Arpad moved to copy the text from Supporting_Files into BIRD179 as part of the editorial process. Bob seconded. No one was opposed. Bob noted that we may want to capture these editorial changes in a document for the Editorial task group. Mike L. noted that we have a document tracking reported editorial issues with previous versions of the spec, but we have no document tracking editorial issues with approved BIRDs. Bob noted that we might want to create such a document and add the BIRD158 and BIRD179 changes to it. Mike L. noted that the Quality group's second question about BIRD179 was about the parameter names themselves. Were they intended to be top level parameters only, or should they be searched for at any level? Arpad said his intention was that they be searched for at every level. Bob agreed, and noted that a parameter name need only be declared in Special_Param_Names once, regardless of where and how many times it was used. - Curtis: Motion to adjourn. - Walter: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 03 April 2018 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives